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ABSTRACT 

The modeler is the person who formulates a problem. The 
modeler's forms of the problem have certain characteristics. 

They are symbolic. They are concise. They are understandable. 
Finally they are general. They are in a form that is easily 
read and comprehended by humans. 

The algorithm is the computational method, that finds 
optimal solution to the modeler's form. Algorithm's forms are 
distinctly different from modeler s forms. They are explicit 
rather than concise. They are convenient rather than under- 
standable. Choice of an algorithm' s form depends on the algo- 
rithm and its implementation. 

Both of the above forms are essential for solving the 
model. Yet the fundamental characteristics of these two forms 
are opposite and incompatible. No single means of expression 
could serve as both a modeler's form and algorithm's form. 

The modeler's form must be transformed into an algorithm’s . 
form before it is solved or analyzed. Since the modeler's form 
is written by a person and algorithm's form is read by a computer, 
translation necessarily entails both humanwork and machine 
computation. The best approach is to leave almost all of the 
work of translation to the computer. 
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Central to such an approach is a computer readable 
Algebraic Modeling System, which e3<presses the model in much 
the same way the modeler does. This work is a modest step to 
develop such a system for linear programming problems, which is 
designed to be simple to learn and easy to use, Ttiis system 
allows the user to specify his LP problems in the natural 
algebraic format. 

The other basic features of this system are: 

1. It accepts all types constraints including range 
constraints. 

2. It introduces slack/surplus variables wherever necessary, 

3. Variables can be both lower bounded and upper bounded. 

4. Variables can be declared as unrestricted. 

5. Problems can be solved by either primal or dual algorithm. 

6. Objective function can be either minimized or maximized. 

7. Problems can be in algebraic format or matrix format. 

In nut shell, the user will not be bothered of details of 
intermediate processing of the model. In its present form this 
system can process the language, solve the problem and give the 
result, but some sophisticated features like sensitivity analysis, 
model editing, model saving etc., can be readily extended. 

This kind of Model Development Aids should lead to the 
more reliable application of the model at lower over all cost. 

, ^ 



CHAPTER I 


INTRODUCTION 


1.1 INTRODUCTIONS 

In the early days of mathematical modeling, algorithmic 
capabilities and raw computational power were the main constraints 
The size and complexity of models were thus severely limited by 
both technical and budgetary constraints. But rapid progress 
in computer technology has alleviated technical and budgetary 
constraints on the size of the mathematical models for which we 
can compute numerical solutions. 

With phenomenal improvement in computing power mathema- 
ticians developed more and more sophisticated models to depict 
a near real world situation. Massive research and development 
efforts in the design and implementation of algorithms have 
yielded some spectacular results. Implementation of algorithms 
have reached a level of reliability and efficiency which can be 
hardly surpassed. Spurred by these developments, the scope of 
mathematical modeling applications has widened and secured a 
solid foothold for itself in almost every field. Models are 
used to simulate, predict or plan the behaviour of physical or 
social systems and, every day thousands of models are pushed 
through computers. 
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As models have growa in size oijr ability to comprehend 
and control them has diminished rapidly. Most of the model repre- 
sentation could only be operated by the original development team. 
Further more, despite the strong efforts in program documentation 
and model representation actual use of these tools other than by 
the original designers has been minimal [ALE 8 IJ. 

Besides the tedious job of translating the model from 
modeler's form to algorithm's form, Johannes [J0H78] identifies 
five other major obstacles before modelers in effectively using 
the available software tools. They are the followings 

1. Model Documentation s 

The documentation of large models and their modifications 
is a major problem. If a project is large and continues for one 
or two years, the cost of complete documentation grows exponen- 
tially, Within a few years, however the value of the available 
software becomes essentially zero, since people change jobs, and 
changes to existing versions reqioire extensive setup cost, 

2. Model Communication g 

A related problem is that of communication of models to 
interested persons outside the project team. A technical person 
is needed to bridge the gap. This may prohibit an outsider from 
even attempting to satisfy their own curiosity with regard to 
the model. 
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3. Model AssiJmptions » 

If models cannot be communicated effectively to outside 
users, there is no way to check the assumptions and data of a 
model. As no one but the researcher has a complete knowledge of 
what went into a model, the published outputs may not necessarily 
reflect the inputs that an outsider assumes. 

4. Model Dissemination g 

Another negative effect of poor communication of models 
to outside users is that no effective dissemination of knowledge 
can take place, 

5. Model Interface s 

With the primitive technology in modeling software, there 
is no common interface with the various solution routines, a 
modeler may want to use for his family of models. As each solu- 
tion package -usually requires different data structures, it 
becomes both time and money consuming to switch back and forth 
between solution algorithms. 

The heart of the problem is the fact that solution algo- 
rithms need a particular data structure and problem representa- 
tion which may be difficult to comprehend by modelers. At the ; 
same time problem representations that are meaningful to modelers 
are not acceptable to machines. The translation process by modeler 
is the main source of difficulties and errors. Here lies the 
bottleneck of model building and model implementation. 
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The best approach to this bottleneck is to develop a 
system which accepts the problem in modeler's form and generates 
the algorithm' s form, thus eliminating the need for tedious and 
error prone human translation. 

1.2 LB3EAR PROGRMCCNG MODELS S 

Linear Programming has become a valuable aid to decision 
making in many fields. Linear programming techniques are widely 
used to solve a number of military, economic, industrial and 
social problems. Three primary reasons for its wide use are 
[PHI76] . 

1. A large variety of problems in diverse fields can be 
represented or at least approximated as linear programming 
models. 

2. Efficient techniques for solving linear programming 
problems are available, and 

3. Ease through which data variation (Sensitivity analysis) 
can be handled through linear programming models. 

1.2.1 Standard Form ? 

In vector notation the standard linear programming prob- 
lem can be expressed asi 

Maximize (Minimize) Z = C X 
Subject to A X = B 

X 2. 0| B > 0. 
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The main features of the standard form ares 


1. The objective function is maximization or minimization 
type. 

2. All constraints are expressed as equations. 

3. All variables are restricted to be negative. 

4. The right hand side constant of each constraint is 
non-negative . 


1.2.2 General Form s 


The general form of linear programming problem isi 
Maximize (Minimize) 


n 

Z c . X . 
3 3 


Subject to 


j=l 

n 


Z a. . X. 

j=l 

^. < X. < u. 
0 ~ ~ 0 


1 < 1 < m 


£. and u. are lower and upper bounds of the variable x. . Any 

J J U 

problem in general form can be converted into standard form 
and then solution algorithm can be applied to arrive at the 
solution. 


1.2.3 Thesis Outline s 

The objective here is to develop a system that can 
translate the modeler ' s general form of linear programming 
problem into algorithm's form and then solve the problem. 



CHif^TER II 


LITERATURE SURVEY 


2.1 ABSTRACT MODELS 

2.1.1 Introduction s 

The standard LP formiLLation has the form 
n 

Z a. . y . < h . , 1 <, i < m (constraints) 

j_l ^0 J ^ “■ 

n 

. Maximize Z c. y. (the objective function) 

1=1 ^ ^ 

But a potential user is not expected to think in terms 
of a. We may conceive of a model verbally by some statements. 

X J 

E.g., A farm manager may conceive his problem in the following 
ways 

1. The total monthly water consumption for all crops must 
not exceed the monthly water allotment. 

2. Maximize total profit from all crops. 

Then the above problem can be written ass 

Z a. . y. < b., i e MONTH 

i s CROP 11 1 ~ 1 

Maximize T c- y . 

j eCROP ^ ^ 
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Observe that CROP and MONTH are natural set of objects. 
Here we call them terns which woiild be defined separately. The . 
abstract mathematical notation is quite concise. However, a 
statement of the problem in English is quite natural and is 
easily understood by hirnian beings. The objective is to think 
for a language which can capture the conciseness of mathematical 
notation. 

The need for abstract model representation stems from 
the following properties of many real life programming problems. 

1. Linear programming variables that f\iLfil logically 
similar roles fall into natural .groupings? e.g., on a farm 
natural groupings might be the crops or the tractors. 

2. Some of the constraints have a similar structure. Again 
consider a farm and assume that the water demand and supply are 
given on a monthly basis. For each month, a constraint is 
required to express the bounds on water supply in that month, 
yielding a set of constraints with similar structure. 

3. Some aspects of a model change more often than others. 

In many cases one conceptual model is applied to different 
sets of numerical values. In other cases some of variables or 
constraints are slightly changed, whereas the model as a whole 
remains its structure. 
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2.1.2 The Terminolog^t^ o 

The abstract model uses the terminology that is defined 
separately. It includes two syntactically distinguishable 
types of identifiers as coefficients, those that represent 
unknown quantities, to which the linear programming solution 
ultimately assigns values (the usual Linear Programming vari- 
ables), and those which represent known quantities (constants). 
Then there is a need to create and maintain a database for 
associating data values to identifiers that represent unknown 
quantities in the model. 

Thus the terminology and the database can be viewed as 
the ENVIRONMENT of the abstract model. T/flien the list of names 
represented by the terminology and the values are provided from 
the database, the abstract model can be interpreted to yield a 
specific concrete model that is in a form ready for solution by 
a Linear Programming system. 

2.1.3 The Advantages ^ 

Though the need for complex language structure will arise, 
the advantages the many fold. For example, if a particular 
numerical value must be updated (e.g., the amount of land avai- 
lable for farming changes), this can be done without affecting 
the terminology of the abstract model. The new components can 
be recombined into a new concrete linear programming model. 
Similarly if a new crop is added to the list of crops in the 
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terminology, this need not influence the abstract model, although 
the numerical information usually will have to be added in the 
database. Another advantage of this kind of system is that the 
database can be updated regularly and used to generate reports 
independent of linear programming context. 

2.1.4 Implementation s 

The goals that influence the high level system and lan- 
guage also affect the implementation decisions that are not 
distinctly visible to the user. Without bothering much for the 
implementation environments the process of implementation can 
be summarized as follows (Fig. l)s [KAT80]. 

1, The abstract model in machine readable form is compiled 
alone without any knowledge of the environment (i.e, terminology 
or the database). The result for each line is a section of 
code in a programming language. This code requires terminology 
and data values as input, and in conjunction with some standard 
system functions will produce a concrete submodel. In addition 
to the code itself, the data references mentioned in the every 
line of the model are produced, as well as two sequences of terms 
those which are used in constants and those which are used in 
variables . 

2, Next, the list of elements associated with the relevant 
variable sets are obtained from the terminology system. 
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3. The list of elements associated with the terms used in 
database are founded. These help determine exactly which data- 
base values are required, 

4. The database is used to obtain the values for the request 
from 1 using the information from 3. 

5. The code generated in 1 is then executed with 2 and 4 
as input, producing a collection of independent concrete sub- 
models. Finally the submodels are combined into one large 
concrete model, where all appearances of the same primitive 
variables are associated. Later a system for solving concrete 
linear programming models can be applied. 

Note if a single line of the abstract model is changed 
steps 1 throxogh 5 above for all other lines are unaffected and 
need not be repeated. If changes are made in the database, 
steps 1 through 3 are unaffected, and a new terminology leaves 
1 unaffected. 

With this kind of implementation at heart some systems 
were developed recently and they were named MATRIX GENERATORS, 

2,1,5 The State of Art s 

Existing matrix generators include DATAFORM, DATAMAT, 
GAMMA, IBM MGRW, PERUSE. ANALYZE etc. [ELLSP], Though these 
systems have quite similar philosophies of design, they differ 
in details. Each of these systems incorporate its own language 
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in which its MG programs are to be written (Translated version 
of model into MG FORJ^l) . Like higher level programming languages, 
these MG languages also differ from one another quite distinc- 
tively, To conve 3 ^ the model to Matrix Generator the user writes 
a Matrix Generator programme which can represent the model to 
MG. Matrix Generator programme has to be written in Matrix 
Generator language which is typical of FORTFLAN, APL etc. Like 
IBM’s ECL (Extended Control Language [SLA78]) can support APL 
executable statements and PERUSE [KUR80J can support FORTRAIsf 
executable statements. In a way these are specially structured 
languages exploiting the nature of the environment (Appendix III). 

2.2 MODELING LANGUAGES S 

There is an attractive alternative to matrix generators 
[F0U83]. It is founded on a simple ideas that modelers should 
deal with the computer directly in modeler's form. To meet this 
an LP modeling language is defined by the following two require- 
ments, 

1. It must be possible to express any linear program 
in modeler's form by the use of modeling language. 

2. It must be possible to create a computer system 
that takes modeling language LP as input and that produces a 
corresponding algorithm's form as output. 
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2.2,1 General Features ? 

A modeling language by definition, must satisfy two 
opposing sets of requirements. One set is imposed by the needs 
of people, and the other by the nature of the computers. 

People want modeling language that is as easy to use 
and to understand as the familiar modeler's form. Thus a 
modeling language needs to organize the terminology that modeler ’ s 
find convenient. The expressions of a modeling language need 
to be as powerful and flexible as subscripting, indexed sums and 
other common notation. 

Computer systems on the other hand, require a modeling 
language that can be processed and translated. Both syntax and 
semantics must be unambiguous and not overly complicated. Unfor- 
tunately modeler's forms are ambiguous and complex (as are natural 
languages generally) and their meanings depend on subtleties of 
context. Moreover important elements of their notation notably 
subscripts and signs - are incompatible with ordinary computer 
hardware . 

Nevertheless, an existing modeler's form is a sensible 
starting point for the design of an attractive and workable 
modeling language. Such a form need only be modified so that 
it can be read and processed by Computer, Most importantly the 
variety and complexity of the existing modeler' s form must be 
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reduced so that every expression has an unambiguous syntax 
and meaning. Notation must be altered to employ a standard 
character set. 

2.2.2 A Prototype ? 

A hypothetical modeling language X]NiL was designed by 
Robert Fourer [F0U83]. The correspondence between modeler’s 
form and XML's form have five major sections^ sets, parameters, 
variables, objectives and constraints. Both have entries within 
sections for individual items (sets, objective, some parameters) 
and for indexed collection of items (other parameters, variables 
and constraints) . 

xml's indexing expressions - such as i over raw (i e raw) 
and t FROM 1 TO time - describe the sets over which collections 
of items are indexed. The members of indexing sets may be num- 
bers or orbitrary strings. XML incorporates set expressions 
that specify unions, intersections complements of sets and 
logical expressions that may include or exclude certain set 
members (for instance, i OVER Prod, j OVER prod when 1 j). 

By use of these set and logical expressions, it is possible to 
specify particular subsets of the data over which variables or 
constraints are to be indexed. 

XML s arithmetic expression have a powerful indexed sum 
( ’ SIGMA' ) notation that corresponds to the algebraic use of E . 
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There are various concession to the standard character set, 
such as SIGMA for and x[j]for x.. As with the modeler s form, 
the XML model describes all of the set and parameter data sym- 
bolically. At a minimum, the XML description lists all of the 
sets and parameters that the model requires and specifies how 
certain parameters must be indexed over the sets? certain sets 
or parameters may also by explicitly defined in terms of others 
to clarify the formulation or simplify expression, 

2.2,3 Implementation of Modeling Language s; 

ML like languages for linear programming have mostly been 
developed in early eighties. The more sophisticated of these 
languages incorporate some kind of s 3 nnbolic indexing, so that 
they can conveniently represent fairly large models. Systems 
that employ these languages are the followings 

a) ALPSs Advanced Linear Programming System 

b) GAMSs General Algebraic Modeling System 

c) LMCs Linear Modeling Capability 

d) LPMODELs Linear Programming Modeling Language 

e) MGGs Matrix Generator Generator 

f) UIMPs User Interface for Mathematical Programming. 

Notably, most of the desirable aspects of an ideal 
modeling language are represented among these seven ^rstems. 

All of their languages resemble modeler' s form to some degree 
and do not involve programming. All allow a row-wise (constraint 
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wise) organization and all use subscripted identifiers. They 
offer various features likes algebraic notation, general linear 
expressions, symbolic sets, parameters declared independent of 
data automatic detection of bounds of some kind etc. 

These implementations suggest both that modeling language 
features can be practical to implement and to use and there has 
been some demand for them. Significantly three of these systems 
(ALPS, MGG, UIMP) are expressly intended for use with large and 
complex LP s. 

2.2.4 Advantage s s 

The voids created by matrix generators have been filled by 
the ML systems. The advantages that accrue are verifiability, 
modifiability, documentability, independence and simplicity. 

a) Verifiability s 

First it is necessary to determine whether the modeler’s 
conception of the L.P, is a proper representation of reality. 

This task the validation of model is independent of computer 
system. 

Second it is necessary to determine whether the ML expres- 
sion of the LP is a proper representation of the modeler’s con- 
ception. It is much easier to debug an ML representation than 
an MG program, since an ML representation is a straight forward 
and understandable version of an LP. By contrast an MG program 
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represents a fairly complex transformation of an LP. 

b) Modifiability s 

For an ML user the job of LP modification reduces to 
determining a new modeler's form. I'lL modifications closely 
resemble actual modifications to the modeler's conception of 
the LP, where as MG modification must be made to a computer 
program that clearly defers from modeler' s conception. 

c ) Documentabilit V s 

Modeler' s form dociamentation can simply be included as 
part of the modeling language since the ML representation is 
itself a modeler s form. 

d) Independence i 

A modeling language describes LP purely in a modeler's 
form, and gives no indication how they are to be translated, 
the means of translation and the identity of algorithm's fom. 

e) Simplicity s 

A modeling language saves its user, any concern with 
intermediate form such as the MG form. An ML user need only 
be concerned with the modeler's form of LP modeling languages 
there by simplify the job of linear programming and in doing 
so they should promote efficiency and reliability of modeling 


as well 



CHAPTER III 


SYSTEM DESIGN 


5.1 INTRODUCTIONS 

Linear Programming has become a valuable aid to decision 
making in many fields. However, the effort that is required 
to collect and organize data, to express a Linear Programming 
(LP) model as a matrix, and to input the matrix of coefficients 
to the computer, iirpedes the use of this valuable tool. We have 
developed a system to help in the process of generating the 
matrix, given the natural algebraic modeler's form. While good 
progress has been made in meeting the needs of a less sophisti- 
cated user, the process of constructing a model is still com- 
plicated. 

The increased availability of interactive terminals and 
the general trend towards providing better programming tools for 
the user have made it natural to consider systems that concentrate 
on the construction and development of Linear Programming models, 
than on their solution. Thus the system developed here, makes 
Linear Programming more accessible to the user who is not an 
expert in Computers or Operations Research, This- interactive 
system simplifies the collection and organization of data. It 
provides a language which frees the user from the necessity of 
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expressing the model as a matrix. The system generates into 
for a standard LP system, which then actually performs the 
optimization of the model. 

The goal of this work is neither to provide yet another 
method for solving Linear Programming problems, nor is to provide 
heuristic guide lines for constructing a Linear Programming 
model. Rather a declarative language is described, which was 
designed to be sufficiently expressive, yet simple to learn 
and use (See Appendix I). The attraction is its naturalness, 
expressing the model interms natural to the domain of the prob- 
lem. For the very same reason the system can be a powerful 
teaching aid also. Note that directly constructing a matrix 
using any programming languages violates, its naturalness. 

3.2 SYSTEM DESIGNS 

Besides the general considerations of simplicity and 
naturalness, some specific properties of Linear Programming 
models were exploited in the system and language design. A 
Linear Programming model consists of a set of linear constraints 
and a linear objective function to be minimized or maximized. 

The most basic property of such a model is that it is declara- 
tive, Another basic property is that various constraints in a 
model are independent. Thus changing one constraint will have 
no effect on others, although it does effect the solution to 
the model. 
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The system can he bisected into Language processor and 
Algorithm implementor. The Language processor parses the input, 
prepares the matrix and sets the options. The Algorithm imple- 
mentor selects the optional algorithm (Primal or Dual), solves 
the problem and prints the results. This system can be run 
either in batch processing mode or in interactive mode. The 
system features are as follows s 

3.2,1 Language Processor ; 

The most basic property of a linear programming model is 
that, it is declarative. To declare the model in machine read- 
able form, a set of reserved words are chosen from the modeler' s 
terminology. The reserved words and their actions are discussed 
in Appendix I. 

The system asks for the declaration of variables the user 
wants to use in his model representation. This is to check the 
variables in the model representation for the possible spelling 
mistakes. Variables will be first sorted using Heap sort algo- 
rithm [HOR76] and Binary search algorithm [KNU 73 ] is used to 
check the variables. But in matrix format representation vari- 
ables will not be sorted and sequential searching will be done 
to check the variables. The user can also generate variables 
using the reserved word 'TO' , 

Since the LP is a continuous optimization problem, the 
relational operator ’>' is treated as ’>=' and the relational 
operator '<' is treated as ’<='• 
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3.2.2 Input Processing s 

The processor cfm accept the general form of LP (Chapter I) 
either in algebraic format or in matrix format depending upon the 
option. The algebraic format of the problem is as follows i 

1. Title 

2. Var 

3. Max (Min) 

4. Constraints 

5. Bounds 

6. Unrestricted 

7. End 

Though the sequence of the above declarations is not mandatory, 
variable declaration should come first, before any variable is 
used in model representation. 

The general matrix format of the LP program is as follows! 

1. Title 

2. Var 

3. Max (Min) 

4. Matrix 

5. Noconstr 

6. Constraints type 

7. Objective function coefficients 

8. Constraint, RHS coefficients 
* End 


9 
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Due to implementation constraints the sequence from 4 to 
8 is rigid. 

The processor parses the input, prepares various 
tables, sets xthe options and calls for the algorithm imple- 
mentor, 

3.2.3 Algorithm Implementor s 

The algorithm implementor has three algorithms. They 

ares 

1. Primal revised simplex [NAR83] 

2. Dual revised simplex [l'IAR83] 

3. Primal revised simplex using upper botmding 
substitution [BRA77] 

The first two algorithms cannot tackle upper bounds and 
are used only when none of the variable is upper bounded. The 
third one is implemented to tackle upper bounds and is called, 
only when atleast one of the variables is upper bounded. This 
is to avoid unnecessary checkings when they are not needed. The 
algorithm implementor is flexible and any algorithm developed 
can be coupled without major changes. Once the algorithm solves 
the problem a print procedure is initiated to output the results. 

3*2,4 Output s 

.Output can be on the terminal or into the file ’OUTPUT’ , 

If the system is run in interactive mode then the output is 
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always on to the terminal. If the system is run in batch 
processing mode then the results will always be written in 
the file OUTPUT , Option is available to get the results on 
to the terminal simultaneously by using the verb ’TALK’ in the 
problem description. Ifllhen used the system comes up with a 
prompt » > I am talking, are you listening' and buzzes the bell. 
System will wait for user response by pressing ’RETURN’. Upon 
user pressing the ' RETURN' the output will be displayed on to 
the terminal. The same procedure will be followed in the inter- 
active mode also. 

3.2.5 Modes 

The system works in the following two modes depending 
on the user options 

1. Interactive 

2. Batch Processing 

In batch processing mode the input is assumed to be in 
the title ' INPUT ’ . If input is nonexistent of does not contain 
the proper input the system gives the message ' > No INPUT file 
or NO DATA in INPUT file' and stops. 

In interactive mode the user enters the problem on the 
terminal directly and whenever he presses RETURN the system 
comes up with the prompt > . If any errors are found the 
system gives the proper message and the user can correct that by 
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keying in afresh. At the end of the prpblem description he has 
to type 'END' . Then the system activates the algorithm implemen- 
tor and solves the problem. After the first problem, the user can 
key-in the second one, the third one and so on. 'STOP’ always 
brings the user out of the system. Online help facility can be 
availed by asking ' HELP ' * 

3.2.6 Online Help ? 

Online help facility is provided by a brief description 
of the system and a set of examples. These examples cover all 
the possible problem representations. 

3.2.7 Intermediate Processing s 

The system automatically inserts slack and surplus vari- 
ables wherever necessary. They can be identified with the name 
-CONSTRn and +CONSTRn respectively where n is the cons- 
traint number in the input sequence. The lower bounded variables 
will be replaced by a corresponding variables. The unrestricted 
variables will be replaced by a corresponding variables. The ; 

unrestricted variables will be replaced by two dummy variables, 
but while printing the results they will be converted back to 
the original form. Left hand side restriction in the range cons- , 
traints is taken as a upper-bounded restriction on the correspond- 
ing slack or surplus variable. All this interaediate processing 
is done in the back ground and the user need not do anything 
explicitly. 



3.3 ILLUSTRATIONS 


Manufacturer Problem s 

Consider the problem of a manufacturer who wishes to 
determine how many Sofas, Chairs, Desks and Bookcases he should 
make in order to optimize the use of his reso\irces. These pro- 
ducts utilize two different types of lumber labeled Type I and 
Type II lumber. He has on hand 1500 board feet of Type I and 
1000 board feet of Type II, He has 800 man hours available for 
the total job that must be utilized. His sales schedule requires ' 
him to make at least 15 desks and 10 bookcases. Each sofas, 
chair, desk and bookcase requires 5, 1, 9, 12 board feet of ! 

Type I lumber and 3, 2, 5, 10 board feet of Type II lumber, A 

table requires 2 man-hours to make, a chair 3, a desk 4 and a 

bookcase 5. The manufacturer makes a total profit of Rs. 12 on 

a table, Rs. 5 on a chair, Rs. 15 on a desk and Rs, 10 on a ; 

bookcase. It is desired to maximize the profit. 

3.3.1 The Modeler' s Form (For more examples see Appendix II) s ; 

The modeler's form of the above problem is stated belows 

Maximizes 12 Sofas + 5 Chairs + 10 Bookcases + 15 Desks i 

Subject tos 5 Sofas i 1 Chair + 9 Desks + 12 Bookcases <_ 15 

3 Sofas + 2 Chairs + 5 Desks + 10 Bookcases <. IG 

2 Sofas + 3 Chairs + 4 Desks + 5 Bookcases = £ 

Desks >, 15, Bookcases ^ 10 
Sofas, Chairs ^ 0 ; 
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3 • 3 . 2 The Algebraic Input ? 

The input to the system for the above problem is» 
VARIABLES 

SOFAS, CHAIRS, DESKS, BOOKCASES ' 

MAXIMIZE 

12S0FAS + 5CHAIRS + 15DESKS + lOBOOKCASES 
CONSTRAINTS 

5 SOFAS + CHAIRS + 9 DESKS + 12 BOOKCASES < 1500 

3 SOFAS + 2 CHAIRS + 5 DESKS + 10 BOOKCASES < 1000 

2 SOFAS + 3 CHAIRS + 4 DESKS + 5 BOOKCASES = 800 

BOUNDS 

DESKS > = 15 
BOOKCASES > 10 

END 

Note the natural algebraic free format used in expressing 
the problem. 

Optimal Value .- 3.3729999959E+03 

Optimal Solution 

Basic variables! 

CHAIRS = 8.4000003337E+01 

SOFAS = 2.1899999678E+02 

+C0NSTR1 = 6.6000018119E+01 
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Non-basic variables^ 

BOOKCASES = l.OOOOOOOOOOE+01 

DESKS = 1.5000000000E+01 

+C0NSTR2 = 0.0000000000 

3.3.3 The Matrix Input s 

The system also accepts the matrix input, since it is 
convenient for the problems generated by other programs* The 
matrix input for the above problems is as follows! 

VAJl 

SOFAS CH4IRS DESKS BOOKCASES 

MAX 

MATRIX 

N0C0NSTR*3 

< < = Constraint type 

12 5 15 10 Objective function 

5 1 9 12 1500 

32 5 10 1000 

2 3 4 5 800 

BOUND 

DESKS >= 15 BOOKCASES >= 10 


END 
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•The system output is as follows s 

OPTIMAL VALUE s 3.3729999959E+03 
OPTIMAL SOLUTION 
Basic variables? 

SOFAS = 2.1899999678E+02 

C MIPS = 8 . 4000003337E +01 

+C0NSTR1 = 6.6000018119E^01. 

Mon-basic variables? 

DESKS = 1 . 5000000000E +01 

BOOKCASES = 1 . OOOOOOOOOOE +01 

+C0NSTR2 = 0.0000000000 

observe that the variables are not sorted in this solution 
contrary to the above solution. 



CH.'\PTER IV 


CONCLUSIONS 


4.1 SUiyMARYs 

Mathematical modeling is a potentially powerful tool in 
the Social Sciences and in Strategic Planning. It will become 
an effective tool only if the costs involved are reduced signi- 
ficantly^ where costs may be measured in monetary units, time 
and human skills. The keir to this all may be found in the 
communication of models. The most efficient and unambiguous 
way to communicate models between humans, should also be the 
way to communicate models with machine. The modeling languages 
developed are a del'inite step in this direction. 

Although a thorough treatment of the Modeling languages is 
avoided due to space constraint and complexity of technical details 
this work demonstrates some of the main features of interest to 
model builders. The compactness and completeness of a Modeling | 
language is an ever ending refining process, through the feedback 
of Modeling langmge users. The struggle to invent systems that : 
can "listen" and "talk" to humans directly, will go on. 

1 

4.2 ACHIEVEMENTSs i 

The system implemented here, is ideal for medium size ; 

dense problems. This system is a veritable teaching aid, as the 
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novice can feel both the input and the output. The system helps \ 
. the beginners in learning it by online help facility and imme- 
diate error checking. It relieves the user, even from the burden 
of converting general form of LP into standard form of LP, 

4.3 LIMITATIONS s 

The system developed here, accepts algebraic input of a 
model in standard algebraic format. E.g. The user expresses the 
constraint ?x + 3y < 100 directly. Constraints in algebraic 
form must be of a very limited sort, loosely tied to the matrix 
formulation. There is no provision for generic constraints and 
each individual constraint must be input with its explicit nume- 
rical coefficients. 

The system cannot handle sparse problems efficiently as 
all the constraint coefficients are stored, rather than storing 
only nonzero coefficients. 

4.4 HJTURE EXTENSIONS? 

This work is a modest attempt in implementing a simple 
and easy to learn system, without losing the naturalness of the 
LP problem. Besides solving a problem the system can have the 
following facilities, to increase the flexibility of handling 
the model and to help the user in learning about the model. 
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( i ) Sensi tiv ity iAnalvsis ^ 

Sensitivity analysis throws lot of insight into the model 
for variations in tho input data. If the system is equipped with 
sensitivity analysis the user can learn about the model and 
its realit3/'. 

( ii ) Mode l Editing s 

Model editing facilities greately enhances the flexi- 
bility of some structural changes in the model representation. 

( i ii ) Saving t he Model - 

After running the model, the user can be given the option 
of saving its numerical information and the result, in a database 
for future use. When the user wants to do sensitivity analysis 
on the model at a later stage, the system need not solve the 
problem ctgnin and can directly start with sensitivity analysis. 
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APPENDIX I 


THE LANGUAGE 

ProblC‘mr» are solved by specifying appropriate control 
phrases, ob.ioctive function, constraints and bounds. The system 
is both intoT'active and batch processor. As many problems as 
desired, may be input during a given run. Each problem is solved 
independently of others. If any fatal error occurs during the 
language processing that problem will be skipped. But subsequent 
problems will be processed. Note that relational operator '< ’ 
is treated as *<=' and '>' is treated as '>='. Now we will 
describe the languages 

1 . 

Blank cards are ignored and may be inserted for 
readability, 

2 , « » 

Comments begin with an asterisk (*) or an exclamatory 
mark (•). These may appear any where in the problem. From that 
point till the end of that line is considered to be a comment. 

3. TITLE 

TITUE of the problem 
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The reserved word TITLE may be used to specify the 

problem title. The title card should be followed by a card 
containini'- the problem title. 

^ TITLE recofjnizes the first 80 characters only 
TITLE 

This problem is referred by DR MRSINGH DEO 

4. PR Wi/ DUAL 

Thf' above card specifies the algorithms to be used. By 
default it solves the problem susing revised primal simplex 
algorithm , 

5. VARIABLES or VAR 

The reserved word VARIABLES (VAR) specifies the variable 
list to folic. . I.i.Iiv„dual variables are named on the card by 
separating each variable name by one or more blanks or by a 
comma , B:<t I AMPS, BULBS FIRE A sequence of variables may be 
defined by declaring varl TO var2 where varl and var2 have 
identical prefixes and the suffixes of varl and var2 are natural 
numbers. The prefix is defined as leading alpha part and the 
suffix is defined ns the trailing numeric list, XI TO X5 would 
define the variablas XI, X2, X3, X4 and X5, 

6. MAXIMIZE or M/iX, MINIMI2E or MIN 

The command MAXIMIZE(MAX) or MINIMIZE(MIN) specifies 

to be either maximized or 


that the objective function is 
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minimized, liivXII'ira*; X1+3X6+X3, MIN 5Y1+6Y3+8.5Y4 The pre- 
sc«ncf'' of rnLsninr cotfficicnt implies a coefficient of +1. 

The absence of a variable implies coefficient of zero. 

7. COHSTItAirn' or CONSTR or CONSTRAINTSs 

The phrasf CONSTRAINTS( CONSTRAINT, CONSTR) indicates that 
the constraint specifications are to follow. 

CONSTFbilHTS 
4X3, ~ '5X^ = 

3X3 - 3X? >= -10 

pro. - X? < 20 

10 <* 4Y1 - 5Y2 < 40 (Range Constraints) 

The proaenco of a variable with a missing coefficient implies 
a coefficient of +'^ . The absence of a variable implies a 
coefficient of zt'ro. Slack and seirplus variables will be 
introducf/d by the systt®. +C0NSTRn represents surplus variable 
and ’’..j'f-.’n reprejH'nts slack variable where 'n' indicates the 
constraint setjuence number in model representation. 

8, UNHESTIilOT or tjl.JFCESTRICTED^ 

This commcind indicates the variable list whose values 
are unrestricted. 

UMtESTRICT 
n, BUDGET 

Variable declaration with TO is not allowed 

IMRESTRICT 

XI TO X4 INViiXID 
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9. BOUND or BOUI'DS;; 

Tho phrase BOUr©(BOUMDS) is used to fix the lower or 
upper bounds on any variable name. Default lower bound is zero 
and default upperbound is infinit^^. Variable declaration with 
'TO' is not allowed. 

BOUIMDS BOUND 

5 >= XI 

XI <= 5 VALID XI TO X5 >= 5 INV^^ID 

5 <= XI <= 10 
XI > 10 

10. INITIAL: 

INITIAL calls for a procedure to print or type the initial 
tableau after converting the problem into standard L.P , 

11. EPSIIDN = l.OE-5 

EPSILON will be followed by a number (between lOE-4 and 

/ 

10E-.8) to be used as the smallest value in problem solving. 

12 . TALK 

TALK enables the results to be typed on the terminal 
during batch processing. 

13. HELP 

HELP enables online help facility. To be used in 


interactive mode 
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14. MATRIX 

M/vTRIX calls for a pi-ocedure which reads the matrix input. 
This should precedt^ NOCONSTR. 

15. NOCOWSTR = n 

’n' indicates the number of constraints. Constraint type 
of all constraints should immediately follov/. '>' indicates 
that the constraint is greater than equal to R.H.S, '<* indicates 
that the constraint is equal to R.H.S. 

RITRIX 
NOCONSTR = 2 
< > 

423 ’ Objective function 

7 3 6 150 1 <= 

445 200 i >= 

16. END 

END indi elites the end of the current description. If 
END is missing between two problems the system skips the former 
problem, reads the later one and messes up the data giving 
unpredictable answers. 

17. STOP 

STOP forces the system to stop after solving the last 
problem. 

See %)pendix II for models represented in this language. 



/iPPENDIX II 


MODEL PvEPRESENTiiTIOK 

Siric(‘ nil these representations are self explanatory. We 
have not j'^ivr-n their modeler's form explicitly. 

1. TTTIE 

D.H, MOTIvU — PIiGE 110 ^3 

VAI^I.iBO'lS 

XI, XP 

MAXIM E2?’ 

8X1 + 8XP 
COIfSTIl/i.TKT.0 
3X1 -‘iX? n 
?u 

XI +PX? <1‘> I Treated as <= 

END 

2« dual I System does not differentiate LC UC 

var » Rev dual simplex has been chosen 

xl to x6 
constr 

4x1 -5x2 +7x3+ x4 -8 
-2x1 +4x2-2x3 +x5* -2 
xl- 3x2 +2x5 +x6 * 2 
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min 

xl +3x? +2x3 

This problem was referred by Dr. Narsingh Deo. 
end 

3. VAR 

XI TO X3 
TITLE 

A problem for unrestricted variables 
MN 

XI +X2 +X3 
CONSTRiilNTS 
XI -3x2 + 4x3 = 5 
xl- 2x2 <= 3 
2x2 - x3 >= ‘^ 

IIMffiSTRTCT 

X3 

DflTIAL * Prints initial tableau 
end 

4. VAR 

Xl TO X3 
MAX 

4X1+2X2 +6X3 


CONSTR 
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AXl -X? <= 9 
-XT +X? + PX3 <= H 
—3^ +X2+^ X3 ‘^=1? 

BOUMDS ' 9ppcr find lower bounds specified 
1 <= XI <=3 
X 2 <= 9 
X 3 <= ? 

END 


5 . 


var 


yi y2 


max 

8 yl + 5 y 2 
constr 

ID <« yi +Ay2 <='^0 i Rj^nge constraints 

15 <w 6 yl •- 4 y 2 <*60 


bound 
xl < ■ 1 ^ 
X? <» 10 
TilLK 
end 
stop 


, Types the results on the teminal 
. Stop after solving this problem 


6. VARIABLES 

^ lA p p 0 

MAXIMIZE 
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4a 2B + 3C 

CONSTRAINT 

7ii + 3B + 6C <= 150 

4A + 4B + 5C < 200 

INITIAL 

EPSIL0N=1.0E*-08 

END 

7 . VARIABLE 
ABC 
M/OC 

M»'ITRIX : Matrix form of the above problem 
N0C0NSTR=2 
< < 

4 2 3 1 Objective function. 

73 6 150 

44 5 200 

EPSIL0N>1.0E~08 
INITIAL 


END 



APPENDIX III 


AN ABSTRACT MODEL 

This appendix illustrates the different forms of LP by 
use of the following elementary production and inventory problem. 

THE problems 

A factory can manufacture some number of different products ' 
over the next, say T production periods. Each product returns a 
characteristic estimated profit per unit, which varies from period 
to period. The factory size imposes a fixed upper limit on the 
total units manufactured per period additionally each product 
requires fixed characteristic amounts of certain raw materials 
per unit. 

Limited quantities of raw materials must be stored now for 
use in the next T periods. Each raw material has a fixed charac-: 
teristic storage cost per unit period. Any material still unused; 
after period T has a certain remaining value. What products . 

should be manufactured in what periods to maximize total expected; 
profit minus total storage costs, adjusted for the remaining 
value of any unused raw materials i 

The Modeler s forms (Abstract Model) 

Given P set of products 

R set of raw materials 
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and T > 0 Number of production periods 

M > 0 Maximum total unit production per period 

^ ior i e R, j e P, Units of raw material i needed to 
manufacture one unit of Product 

0 For i e Rs Max initial stock of raw material i 
c^^ P'or j e P, t = 1...TS estimated profit per unit of 
product i in period t. 

di For i E Rs Storage cost per period per unit of raw 
material i. 

f^ For i £ Ro estimated remaining value per unit of raw 
material i after last period 


Defines x., > 0 for j e P, t = l...Ts Units of product j 

manufactured in period t, > For i e R, t = 1...T+1S 

Stock of raw material i at the beginning of period t. 


Maximize 


T 


^ ^ ^ *^i ^it^ ^ ^i ^i 

•-T ipR ^ teR ^ > 


T+1 


t=l jeP isR ^ "" ieR 

Total overall periods of estimated profit less storage 
cost, plus value of remaining raw materials after:: last 
period. 

Subject tos 


2 X . . < M 

JeP 

For t = 1...TS Total unit production per period must not 


exceed maximum. 
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i e Rs stock for period one must not exceed 
maximum. 

= ®it - 

For i £ R, t = l..,Ts Stock for next period 
equals stock for present period less raw materials used in 
present period. 

M atr ix Gener at or _ s, Fp.rm (Using MaGen Matrix Generator Language) s 

DICTIONARY 


CLASS T 

Set of production periods 

1,2,3 


CLASS U 

Set of periods preceding production periods 

0,1,2 


CLASS V 

Extra period after last production period 

4 


CLASS W 

•2 

Period preceding extra period 

CL«iSS PRD 

Set of products 

LOW 

Low quality product 

MED 

Medium quality product 

HIH 

High quality product 

CLASS RAW 

Set of raw materials 

SCR 

SCRAP raw material 


new raw material 


NEW 
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DATA 



TABLE 

M 

Maximum total unit production per period 


MAX 


MAX 

40 


TABLE 

A 

Unit of raw material needed to manufacture unit o 


LOW 

r^ED HIH each product. 

SCR 

5 

5 1 

NEW 

1 

2 3 

TABLE 

B 

Maximum initial stock of raw material 


MAX 


SCR 

400 


NEW 

275 


TABLE 

C 

Estimated profit per unit product in each period 


1 

2 3 

LOW 

25 

20 10 

MED 

50 

50 50 

HIM 

75 

80 100 ' 

TABLE 

D 

Storage cost per unit for each raw material. 


STOR 


SCR 

0.5 

1 

NEW 

. 2.0 

O ‘ 

TABLE 

F 

Remaining value for each raw m^erial after last 


VALUE 

period 

SCR 

15 


NEW 

25 

1 
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ROWS SECTION 

COPY 

NAJME S.\MPLE 
FORM ROW ID 
obj = obj 

* Balance production and stock of each raw material in each 

* period 

BAL (R/iW)(T) = FIX 

* Limited total production in each period 
Cj\P(T) = MAX 

COLUMNS SECTION 

* 

COPY 

COLUMNS 

x- Manufacturing activity for each product in each period 

FORM VECTOR X(PRD)(T) ' 

X- Consumption of each raw material by each product in each perip 

BAI.(RAW)(T) = TABLE A( (ORD) , (RAW) ) 

* Consumption of capacity in each period i 

CAP(T) = 1 I 

* Estimated profit from each product in each period ! 

OBJ = TABLE C((:T), (PRD)) : 

* Stock piling , activity for each raw material 
FORM VECTOR S(RAW)(T) 
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* Production of each raw material from stocks, start of each 

* period 

BAL (RAW)(T) = -1 

* Consumption of each raw material into stocks after each 

* period 

BA.L(RAW)(U/T) = 1 EXCEPT T = 1 

* Storage costs for each raw material in each period 
OBJ = -TilBIE D(STOR, (RAW)) 

* Stock piling activity for each raw material after last period 
FORM VECTOR S(RA¥)(V) 

* Consumption of each raw material into stocks after last 
»■ period 

BAL (RAW)(W/V) = 1 

* Remaining value, for each raw material after last period 
OBJ = TyJ3LE F( VALUE, (RAW)) 

RHS SECTION 

COPY 

RHS 

FORM VECTOR RHSIDE 

* Production capacity in each period 
CAP(T) = TABLE M(MAX,M.V5C) 
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BOUNDS SECTION 

COPY 

BOUNDS 

FOFtt'I BOUl'.DS MX STOCK 

* Limit on stock of each raw material initially 
S(RAW)l, UP = T/iBLE (M.IX, (M¥)) 

END 

Modeling Language For m" (XML) 

SETS 

Prod COMMENT Set of products 

raw COMMENT Set of raw materials 

PARi'lMETERS 


time 

ATTRIBUTES 

Positive, integer 


COMIffiNT 

number of production period 

max 

ATTRIBUTES 

positive 


COMMENT 

maximum total unit production 

bb 

INDEXING 

OVER raw 1 b[lj 

c 

INUICaUG 

OVER prod, FROM 1 TO time I c[a,t] 

d 

II'JDEXING 

OVER raw, : d[i] 

f 

INDEXING 

OVER raw i f[ij 


VARIABLES 

X 


INDEXING OVER Prod, FROM 1 to time ] X[j, t] 
INDEXING OVER raw, FROM 1 to time + 1 I S [i, t] 
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OBJECTIVE 

CONSTR/iINTS 

limit 

init 

bal 


ATTRIBUTE MAXIMIZE 
SPECIFICATION SIGMA t FROM 1 TO time 

(SIGm j OVER Prod (c[j,t]-)^ x[a,tj) 
-(SIGMil i OVER raw (d [iJ* s[i 5 t])) 
+SIGMA i OVER raw (f[ij ^sLijT+l]) 


INDEXING t FROM 1 TO time 

SPECIFICii-TION SIGMA j OVER Prod (x[j,t]) <v= max 

INDEXING i OVER raw 

SPECIFiavTION s[i,l] <= t[ij 

INDEXING i OVER raw, t FROM 1 TO time 

SPECIFICATION s[i,t+l] = s[i,t] 

-SIGMA j OVER Prod (a[i,j]^ x[d,t]) 


END 
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